In 3GPP the evolution of the system architecture is specified in the standards (3GPP TS 23.401 and 3GPP TS 23.402). One aspect of the evolution is the support of 3GPP (3rd Generation Partnership Project) access (e.g. GERAN (GSM/Edge Radio Access Network), UTRAN (UMTS Terrestrial Radio Access Network), E-UTRAN (Evolved-UTRAN)), non-3GPP accesses (e.g. WLAN (Wireless Local Area Network), WiMAX (Worldwide Interoperability for Microwave Access), 3GPP2 (3rd Generation Partnership Project 2), etc.) and also mobility between them. The anchor for the mobility between the 3GPP and the non-3GPP accesses is a Gateway in the 3GPP Core Network, that also provides the interface to the external Packet Data Network (PDN), and is called PDN GW. The mobility between 3GPP and non-3GPP accesses is based on Mobile IP, whereby the protocol used can be either Client Mobile IP (D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, RFC 3775, June 2004; H. Soliman, “Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)”, draft-ietf-mip6-nemo-v4traversal-04.txt, March 2007) or Proxy Mobile IP (S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, B. Patil, “Proxy Mobile IPv6”, draft-ietf-netlmm-proxymip6-00.txt, April 2007). The non-3GPP accesses are separated into trusted accesses and untrusted accesses. The assumption for untrusted accesses is, that a UE (User Equipment) in an untrusted access needs first a secure tunnel (based on IPsec (Internet Protocol Security)) to an evolved Packet Data Gateway (ePDG) before being able to access operator services. The ePDG is similar to the PDG used for Interworking WLAN (described in TS 23.234). On the other hand from trusted accesses this secure tunnel is not needed. Whether a non-3GPP access is trusted or not is an operator decision and may be different from operator to operator.
For mobility within the same or between different non-3GPP accesses similar mechanisms can be used as for mobility between 3GPP and non-3GPP accesses, i.e. Client or Proxy Mobile IP (Internet Protocol).
As described above, 2 different types of non-3GPP accesses are defined, i.e. untrusted non-3GPP access and trusted non-3GPP access, and whether a non-3GPP access is trusted or not is left to the 3GPP operator. Furthermore, a non-3GPP access may be a trusted access for one UE from an operator A and an untrusted access for another UE from operator A.
When the UE moves into or attaches initially in an untrusted non-3GPP access (FIG. 1), it has to discover an ePDG first, establish an IPsec Key Exchange IKEv2/IPsec tunnel with the ePDG and can connect to the Evolved Packet Core EPC (PDN GW) over the ePDG IPsec tunnel. On the other hand when the UE moves into or attaches initially in a trusted non-3GPP access (FIG. 2) it can connect directly to the EPC (PDN GW).
The problem is that during initial attach or after handover to non-3GPP access (FIG. 3), UE does not know whether the access is trusted or untrusted and if:                a tunnel to ePDG should be established and then afterwards a BU message can be sent to PDN GW, or        BU message can be sent to PDN GW directly.        
As described above, a UE, starting connection establishment with a non-3GPP access network (after handover or with initial attach), may not know whether the non-3GPP access network is trusted or untrusted.
Several possible solutions exist regarding how the UE may detect the trust relationship of the non-3GPP access network. Some of the solutions are described in the following and also possible problems with these solutions are highlighted:    1. Some Radio Access Technologies (RATs) are trusted by default (WiMAX) and others are untrusted by default (WLAN 802.11). The problem with this solution is, that it may not be true, because it could be an operator's decision whether a RAT is trusted or not. Further it may depend on the UE capabilities whether a non-3GPP access is trusted for this UE or not, e.g. it could be trusted if the UE supports specific security means.    2. The UE is pre-configured with a list of network prefixes from trusted non-3GPP accesses. The problem here is that this list can get quite large, for example if an operator has trust relationships with a large number of small non-3GPP access hotspot operators. Furthermore, new non-3GPP access networks may join continually and thus the list must be kept up to date and this could be difficult or rather inefficient if there are a large number of UEs that must be updated.    3. The UE may be informed during AAA (Authentication, Authorisation and Accounting) procedures, e.g. by EAP (Extensible Authentication Protocol) extensions. This solution requires support from local non-3GPP access AAA protocols and infrastructure, however it can not be assumed that this is always supported.    4. The UE is informed by lower layer information (e.g. on L2). Also here the problem is, that it requires support from the non-3GPP access network, i.e. the lower layers (e.g. by some means provided by IEEE 802.11u or IEEE 802.21).    5. The UE tries to establish the connection to the PDN GW, i.e. sends a Binding Update directly to the PDN GW address (or to PDN GW and ePDG in parallel) and if the establishment to the PDN GW fails (because the PDN GW is not reachable from the untrusted non-3GPP access), the UE knows that it is in an untrusted non-3GPP access and the ePDG must be used. The Problem is that the UE must try several times to reach the PDN GW until it can reliable conclude that the PDN GW is not reachable, thus the procedure is very slow.    6. The UE always uses the ePDG first, i.e. establishes the tunnel to an ePDG, and if the non-3GPP access is trusted, the UE is informed to connect to the PDN GW directly. The problem with this solution is, that it consumes higher resources at the beginning, because all packets are double tunnelled (IPsec+MIP tunnel) and routed over the ePDG, thus it is not very efficient.    7. The UE may ask a DHCP server (R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, RFC 3315, July 2003) if it is in a trusted or untrusted non-3GPP access. Here, at first the UE connects to the non-3GPP access and the L2 access is established. Then the UE requests a DHCP server about the trust relationship (including its identity, e.g. in form of a NAI, and/or also the user's home operator identifier). If the non-3GPP access is trusted for the user's home operator and for the user, the DHCP server informs the user about the trust relationship and may return in addition an IP address of the PDN GW. If the non-3GPP access is untrusted for the user's home operator and the user, the DHCP server informs the user about the trust relationship and may return in addition an IP address of the ePDG. Problem here is, that this solution requires a pre-configured entry in the local DHCP server or support by the AAA infrastructure, so that the DHCP server is updated with information for the UE during the access authentication of the UE. But if this is not available, DHCP may not be able to return a valid IP address. In this case the UE may use an ePDG per default. However, this process might be slow.    8. The UE may ask a DNS server if it is in a trusted or untrusted non-3GPP access. Here, at first the UE connects to the non-3GPP access and establishes L2 and L3 access. Then, the UE may construct an UE or operator specific FQDN (Fully Qualified Domain Name), e.g. for the service or PDN, for example as follows:
FQDN=<pdn>.<non-3gpp>.<hplmn>.3gppnetwork.orgorFQDN= <pdn>.<user id>.<non-3gpp>.<hplmn>.3gppnetwork.org     Here the hplmn part is an identifier of the user's home operator, e.g. the MNC (Mobile Network Code) and MCC (Mobile Country Code) codes, the non-3GPP part is some information about the non-3GPP network, e.g. an advertised Network Access identifier or the advertised IP prefix, the user id part is an identifier of the user, e.g. a NAI (Network Access Identifier). The UE asks the DNS (Domain Name Server) system about this specific FQDN and the DNS request will be resolved recursively. If it can not be resolved by a previous DNS server, it will be finally resolved by the DNS server of the UE's home operator. If the non-3GPP access is untrusted, the DNS server will provide an ePDG together with an IP address. Then the UE should establish a tunnel to the ePDG and send the BU to the PDN GW over the tunnel. If the non-3GPP access is trusted, the DNS server will provide a PDN GW together with an IP address. Then the UE should send the BU to the PDN GW directly. Problem here could be that the resolution is quite slow.